Device-to-device communication is a well-known and widely used component of many existing wireless technologies, including ad hoc and cellular networks. Examples include Bluetooth and several variants of the IEEE 802.11 standards suite, such as Wi-Fi Direct. These systems operate in unlicensed spectrum.
Device-to-device (D2D) communications as an underlay to cellular networks has been proposed as a means to take advantage of the proximity of communicating devices and to allow devices to operate in a controlled to interference environment. Typically, it is suggested that such D2D communication shares the same spectrum as the cellular system, for example, by reserving some of the cellular uplink resources for D2D communication. Allocating dedicated spectrum for D2D purposes is a less likely alternative as spectrum is a scarce resource and (dynamic) sharing between the D2D services and cellular services is more flexible and provides higher spectrum efficiency.
The transmission mode when sending data during D2D communication may be (1) unicast—a specific wireless device (WD) is the receiver; (2) multicast (may also be denoted group cast)—a specific group of WDs are the receivers; or (3) broadcast—any WD may be a receiver.
Where there is no cellular network support for D2D communication, data can be sent from one device to another device without prior arrangement. This may reduce the overhead and increase the communication capacity, which is crucial in emergency situations. In such a scenario, the source device transmits data to one (unicast) or more (multicast/group cast/broadcast) other devices, without first ensuring that the recipients are available and ready to receive the data. While such communication may be used for one-to-one or one-to-many communication, it is particularly effective for multicast and broadcast transmissions. The communication may be realized, for example, via physical layer (PHY) unicast/multicast/group cast/broadcast transmissions. With PHY broadcast transmissions, the transmissions may still be turned into unicast/group cast/multicast at higher layers. For example, in the MAC layer, multicast or even unicast addresses may be used. Alternatively, if using broadcast on both PHY and MAC, multicast or unicast IP addresses may be used at the IP layer.
One of the ways to efficiently support D2D communication is to use a scheduling assignment (SA) followed by the data transmission. SAs are control messages used for the direct scheduling of D2D communication. SAs are transmitted by the WD that intends to transmit D2D data and they are received by the WDs that are potentially interested in such data. The SAs are transmitted on dedicated resources characterized by time and frequency, and are typically a sparse resource. For example, a dedicated radio physical channel called PSCCH (Physical Sidelink Control Channel) may be allocated to convey SA information. SAs provide useful information that can be used by the receiver. For example, the informant in the SA may be used to correctly decode the D2D data transmission associated with the SA (e.g., the resources for data transmission, the modulation/coding parameters, timing information, identities for the transmitter and/or receiver, etc.). In particular, in 3GPP parlance standardized SA information is conveyed in the so-called SCI (Sidelink Control Information) format 0, in the PSCCH channel. Typically, but not always, SAs are transmitted prior to the actual data transmission. This may allow a receiver to selectively receive data based on the content of the SAs. The data transmission scheduled by an SA is sometimes called a “transmission pattern”.
As an example, consider the situation in which WD-A is to transmit data to WD-B, where both WDs are outside network coverage at the time of data transmission. In such a scenario, WD-A and WD-B both need to be preconfigured with certain information to be able to send and receive data (e.g., resource pool information, such as time and frequency configuration). When WD-A needs to transmit data to WD-B it typically first sends a sync signal. The sync signal is later used as a time reference by WD-B. The next step is for WD-A to transmit an SA, followed by the actual data.
As long as a group of WDs operate within coverage of a communications network, such as a cellular network, signalling can use the existing paths controlled by the base station. However, if the same group of WDs is out of coverage or the WDs are RRC_IDLE (no network control possible), all communication, including signalling, needs to use a direct interface (referred to as PC5 in the specifications).
According to certain 3GPP groups (e.g., 3GPP TSG SA WG1) requirements for Proximity Service (ProSe) communication should provide the means to give some users and/or groups higher priority when transmitting data. Such priority to may be static or dynamic. Priority defines who gets to transmit first when there is a shortage of resources (e.g. when only one transmission at a time is allowed). Further, priority is used to decide if pre-emption is required in order to ensure that the correct transmitter is allowed to transmit.
ProSe functions provision the WD with ProSe Layer-2 Group ID(s) and associated subscribed Group Priorit(ies). The actual provisioning can be done in a number of different ways. For example, while in coverage, the WD is provisioned over the PC3 interface. However, since there may be a case where a WD is first powered on at a location where there is no network coverage, the WD may be pre-provisioned as well.
The provisioning described so far refers to static priorities, which requires no new functionality. User Static Attributes include information categorizing the user (e.g., first responder, second responder, supervisor, dispatcher, and administrator) as well as jurisdictional boundaries and possibly, a preconfigured system-wide individual priority level (e.g., the fire chief of a particular town or district).
Group Static Attributes include information about the nature/type of the group and the owning agency(ies), the jurisdictional boundaries for transmitters and receivers within the group, the normal hours of operation for the group, pre-emption dispositions relative to other groups, and the default minimum priority of the group (the minimum priority characteristics that are guaranteed to all the participants in a group call associated with this group, regardless of their individual priority characteristics).
Dynamic priorities cannot be provisioned in advance since they are a result of a specific situation. User Dynamic Attributes include the user/participant's operational status (e.g. on/off duty), the user's location, the type of incident in which the user is involved (e.g. mission critical push to talk (MCPTT) Emergency or Imminent Peril), whether or not the user initiated the incident, whether it is a formally managed incident and if it is, the boundaries of the incident area, the incident severity and the user's assigned role in the resolution of the incident. Group Dynamic Attributes, similar to user dynamic attributes, include the type of incident (e.g. MCPTT Emergency or Imminent Peril), if any, the group is currently handling and, in case of involvement in a formally managed incident, the boundaries of the incident area and the incident severity. Given the nature of such dynamic priorities it is important that such priorities are distributed to all WDs in a group and also enforced quickly. However, no such mechanism currently exists for wireless communication.